POV-Ray : Newsgroups : povray.unofficial.patches : Comments requested : Comments requested Server Time
2 Nov 2024 09:18:19 EDT (-0400)
  Comments requested  
From: Nathan Kopp
Date: 10 Dec 1999 22:48:17
Message: <3851c981@news.povray.org>
I would like to hear comments and discussion on my implementations of motion
blur and persistent objects/variables.  Please read all of the documentation
first.  Some thoughts I have are these:

=================
- Persistent Variables -
=================

I opted for the all-or-nothing approach.  Either all variables are
persistent or none are.  This was by far the easiest and cleanest way to do
this.  Does this provide enough functionality?  (Remember, you can #undef
objects if you don't want them to be persistent.)

=================
- Persisten Objects -
=================

I want a consistent way of naming objects.  I don't like using one way to
name variables and another to name scene objects.  This is the reason I came
up with the #create= way of naming scene objects.

I ran into problems with whether to allow duplicate names.  The problem is
that not allowing duplicate labels for scene objects is tough, since there
is scope involved.  For example, if you have object "abc" inside a CSG
difference, it should not conflict with another object named "abc" which is
a frame-level object.  As it turns out, trying to code this into the
existing POV parser could get very messy, which means it would take a lot of
work and could easily have many bugs.  Then, if unions get split up (which
usually happens for speed reasons), things get really crazy.

I would like it if names for variables (created using #local or #declare)
and labeles for objects (created with label or #create) could be used
interchangeably.  For example, it would be nice to use modify{} on a
#declared object or to be able to make a copy of a #created object by using
another #create.  Although these are not necessary, the would make the
language more complete.  Unfortunately, this is also quite difficult to
implement and raises a variety of scoping issues.

Because scene objects can share labels, the object modifiers between the "{"
and "}" of the modify{} 'command' get parsed many times.  This could be
quite confusing to unsuspecting users.  Should modify be changed to #modify
to signify this?  Note that the syntax would be:
#modify{
  name
  modifiers
}
and NOT
#modify
  name
  modifiers
#end
The curly braces would have to remain due to the fact that
Parse_Object_Mods() expects to see the end curly brace.  Also that using
curly braces with #default is done, so this would not be unprescedented.

It would be nice to change more about objects than just their modifiers
(like moving control points of a bezier patch or moving vertices in a mesh).
However, major decisions about implementation standards and syntax need to
be made before this can be done.

=================
- Motion Blur -
=================

Similar concern as with modify{}, since the creation of the motion blur
object causes that section of the POV file to be parsed multiple times.
Unfortunately, this time a directive (with a #) would not be good, since
this is an object type and you need to do something like:
#declare myMotionBlurObject=motion_blur{
  sphere{clock,<0,0,0>}
  translate clock*x
}

Do you think this is a major problem or would good documentation and ample
warnings ward off confusion among users.  What I am worried about is
something like this:

#declare i=0;
#while(i<10)
motion_blur{
  myObject
  translate clock*x
  #declare i=i+1;
}
#end

Note how i would get 1 added to it many times before you got out of the
motion_blur object definition.  motion_blur{} is almost like an implied
#while loop.

-Nathan


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.